The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In data processing the need to provide for interoperation of computer software implementations of different versions, arises in certain contexts. Consider a system that is configured with redundant processors where one or more processors provide service as the Active processor while another redundant processor acts as the Standby that provides a backup for one or more Active processors. The Active processor communicates state information to the Standby processor so that the Standby processor may assume the role of an Active processor at any time after initial state synchronization has been accomplished. During normal system operation, the Standby processor waits to assume control should an Active processor fail or should an external agent request the Standby processor to assume the role of an Active processor. The procedure by which the Standby processor assumes the role of an Active processor is referred to herein as a “switchover.” Because software components running in the Active and Standby processors exchange state information during normal operation and a Standby application is always kept in the same state as its corresponding Active peer, the switchover process is termed “stateful switchover.”
During normal operation, during an equipment upgrade, or during a software upgrade or downgrade operation, the Active and Standby processors may be of different hardware revision or capability, or the Active and Standby processors may be running different software or firmware images containing code at different release levels. In such circumstances, ensuring the ability to compatibly communicate state information between the Active and Standby processors is essential for providing non-disruptive or minimally disruptive switchover and, thereby, non-disruptive or minimally disruptive hardware or software upgrade and downgrade.
In computer network environments that use packet-switched routing, users desire to have a way to accomplish stateful switchover from an Active router to a Standby router without service interruption, even when the Active and Standby routers have different versions of network operating system or other software or firmware running. Users desire this capability to accomplish a “hitless” upgrade/downgrade. Thus, there are two reasons for wanting a “hitless” stateful switchover: to provide protection against unplanned outages (failures); and to provide the capability to allow software and/or hardware upgrades in a hitless manner for planned outages (upgrades).
The ability of the Active and Standby peers to exchange state information must be determined before the peer applications begin to interoperate. Assuming that the Active and Standby peers can successfully exchange state information until the time some incompatibility is detected, and then to attempt a failure recovery, is not feasible. Instead, interoperability must be determined when the two processors and software or firmware images begin to communicate as a redundant system, so that the system configures itself appropriately and behaves correctly before, during, and after switchover. Some method of determining interoperability early on is therefore required.
Manual methods of determining overall system interoperability are both resource intensive and error prone. An automatic method is required. In addition, if a given feature or application included in an image is incompatible but never used by a particular customer, from that customer's point of view, the two releases are compatible. Declaring the images incompatible because one or more unused features are incompatible is possible, but does not provide any advantage to the user.
Based on the foregoing, there is a clear need for a way to determine whether a plurality of software implementations of different versions are interoperable.
There is a specific need for a way to determine whether peer processors, one Active, one Standby in a distributed router for a packet-switched network can intercommunicate, where the processors each may execute an operating system, applications or firmware of a different version. A similar need exists with respect to line cards.